Unify StubLinker stub memory management with JIT code allocator - #131903

src/coreclr/vm/comdelegate.cpp:824

• The comment says this method returns a LoaderHeap, but it now returns a LoaderAllocator*. Updating the comment avoids misleading future readers about what lifetime guarantee is being relied on here.

// We need a LoaderHeap that lives at least as long as the DelegateEEClass, but ideally no longer
LoaderAllocator *DelegateEEClass::GetStubHeap()

src/coreclr/vm/class.h:1925

• This comment still refers to returning a LoaderHeap, but the method now returns a LoaderAllocator*. Keeping the comment accurate is important since this is the declaration most readers will see.

    // We need a LoaderHeap that lives at least as long as the DelegateEEClass, but ideally no longer
    LoaderAllocator *GetStubHeap();

src/coreclr/debug/daccess/request.cpp:3686

• LoaderAllocatorLoaderHeapNames is out of sync with GetLoaderAllocatorHeaps(): the names array includes both "ExecutableStubHeap" and "ExecutableHeap", but GetLoaderAllocatorHeaps() now only returns one executable heap pointer at that slot. This makes GetLoaderAllocatorHeapNames() report a different count/order than the returned heap addresses, which can confuse SOS/DAC consumers.

    "ExecutableStubHeap",
    "ExecutableHeap",
    "FixupPrecodeHeap",

src/coreclr/vm/eventtrace.cpp:3626

• StubInitialized now reports a hard-coded helper size of 1 byte, which looks like a placeholder after removing Stub::RecoverStubAndSize. This will produce incorrect ETW MethodLoad events (size is part of the payload) for write-barrier helpers and any other helpers that call into this path.

Consider restoring a real size calculation (e.g., change StubInitialized to take a size parameter and pass the known helper size from the call sites), or otherwise derive the helper size from the allocation metadata instead of a constant.

            DWORD dwHelperSize = 1;

src/coreclr/vm/stubcache.h:47

• StubCacheBase allows a default NULL loader allocator, but StubLinker::Link ultimately calls EEJitManager::AllocCodeFragmentBlock, which has a PRECONDITION(pLoaderAllocator != NULL). This makes the API foot-gun: any future (or accidental) default construction would crash/assert. Make the requirement explicit by removing the default argument (and optionally assert non-null in the constructor).

    StubCacheBase(LoaderAllocator *pLoaderAllocator = NULL);

src/coreclr/vm/eventtrace.cpp:3627

• dwHelperSize is now hardcoded to 1, so ETW MethodLoadVerbose will report every helper stub as a 1-byte method. That’s very likely misleading for diagnostics tooling that expects size/range information. If the size is no longer recoverable from a Stub header, consider plumbing the size from the call site (e.g., write-barrier helper generation knows sizes) or adding a helper to derive the real stub/code-fragment size from allocation metadata; if neither is possible, please add an explicit comment explaining why reporting size=1 is acceptable.

            DWORD dwHelperSize = 1;
            ETW::MethodLog::SendHelperEvent(ullHelperStartAddress, dwHelperSize, pHelperName);

src/coreclr/vm/codeman.h:131

• GetStubCodeBlockKindString no longer returns accurate names for several stub kinds: STUB_CODE_BLOCK_DYNAMICHELPER and STUB_CODE_BLOCK_FIXUPPRECODE both return "MethodCallThunk", and STUB_CODE_BLOCK_STUBPRECODE is not handled at all (falls through to "Unknown"). This breaks perfmap/event naming for these stubs and makes it harder to diagnose stub allocations.

    case STUB_CODE_BLOCK_JUMPSTUB:
        return "JumpStub";
    case STUB_CODE_BLOCK_DYNAMICHELPER:
        return "MethodCallThunk";
    case STUB_CODE_BLOCK_FIXUPPRECODE:
        return "MethodCallThunk";
#ifdef FEATURE_VIRTUAL_STUB_DISPATCH

src/coreclr/vm/eventtrace.cpp:3628

• StubInitialized now reports a hardcoded helper size of 1 byte. This value is emitted into FireEtwMethodLoadVerbose_V1 and will produce incorrect ETW method-load metadata for helper stubs (notably the write barrier helpers reported from threads.cpp). The size should either be computed from the actual stub allocation or passed in by the caller that knows the exact size.

        if(ETW_TRACING_CATEGORY_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_DOTNET_Context,
                                        TRACE_LEVEL_INFORMATION,
                                        CLR_JIT_KEYWORD))
        {
            DWORD dwHelperSize = 1;
            ETW::MethodLog::SendHelperEvent(ullHelperStartAddress, dwHelperSize, pHelperName);
        }

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/ExecutionManager/ExecutionManagerCore.cs:107

• StubKind was extended with WrapperStub and ShuffleThunk, but GetStubKind(StubKind stubKind) (later in this file) does not map these new values to any CodeKind, so these stubs will be reported as CodeKind.Unknown via GetCodeKind when walking range-list stubs. Either map them to an existing CodeKind (e.g., MethodCallThunk) or extend CodeKind if tools need to distinguish them.

src/coreclr/vm/stubmgr.cpp:1265

• StubLinkStubManager::CheckIsStub_Internal now unconditionally returns FALSE. Since this type still exists as a StubManager implementation, this makes its stub-identification behavior incorrect and brittle if any caller ever queries this manager directly (or if stub-manager ordering changes). It can safely determine membership by checking the code-fragment kind via RangeSectionStubManager::GetStubKind (the same mechanism used by DoTraceStub/TraceManager).

src/coreclr/vm/codeman.h:130

• GetStubCodeBlockKindString returns "MethodCallThunk" for STUB_CODE_BLOCK_DYNAMICHELPER and STUB_CODE_BLOCK_FIXUPPRECODE, and STUB_CODE_BLOCK_STUBPRECODE isn't handled at all. This makes perfmap stub-block names misleading and can cause StubPrecode blocks to show up as "Unknown".

    case STUB_CODE_BLOCK_DYNAMICHELPER:
        return "MethodCallThunk";
    case STUB_CODE_BLOCK_FIXUPPRECODE:
        return "MethodCallThunk";

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IExecutionManager.cs:64

• This adds new public API surface to the cDAC abstractions (CodeKind.WrapperStub / CodeKind.ShuffleThunk). Per dotnet/runtime process, new public APIs require a linked approved API issue (api-approved) or the new surface needs to stay internal until approval is obtained.